There is an idea that was popularized a few years ago that if you change WordPress table prefix in your database, it helps protect your WordPress website from attackers.

Changing your WordPress table prefix is risky to implement and it does absolutely nothing to enhance your site security. In today’s post I’m going to explain what the original idea is behind this and why you should simply not do it.

There is a certain kind of attack called a SQL injection attack where an attacker uses a vulnerability in an application, like a WordPress plugin, to gain access to your database. Using SQL injection, an attacker essentially gains the same level of access to your database that your own WordPress website has.

I’m vastly oversimplifying SQL injection for the sake of brevity. We go into more detail about SQL injection in our WordPress Security Learning Center if you’re interested.

The important concept to grasp here is that, once an attacker succeeds at gaining access to your database, they have access to everything that your WordPress site does. They can usually run any SQL command and can see the output. [Except in the case of blind SQL, but that’s beyond the scope of this post]

An idea became popular a few years ago that went something like this: If an attacker has access to your database via SQL injection, you can prevent them from accessing your data by renaming your tables to some unique prefix.

Once that idea was popular and generally accepted, several security products for WordPress started offering the ability to help you rename your database tables.

That was it. The idea was generally accepted and because security vendors were offering the feature, it was generally accepted as fact.

What if I told you that a great way to prevent burglaries is to turn off all the lights in your home? That way a burglar would be able to gain entry, but they would not be able to see where your stuff is and so they couldn’t steal it.

You’d tell me that the burglar would either bring a flashlight or turn on the lights themselves.

It’s exactly the same concept when it comes to renaming your WordPress database table prefix. Once an attacker can access your database using SQL injection, they are inside your home. If you rename your database tables using a unique prefix, you’ve turned out the lights in your home.

So what’s the first thing an attacker does? They do this:

Let’s look at what the output of this query is:

The above query simply asks the database what WordPress table prefix is being used for the postmeta table. It turns on the lights.

Any bot, attack script or manual attack, using a tool like sqlmap, will always run a query like the above before assuming any default table prefix.

Changing your WordPress table prefix for security reasons does not make a SQL injection attack “slightly harder” for attackers. They simply run the above query before assuming your tables have a default prefix.

Suggesting that this improves security is like assuming a thief won’t bring a flashlight to a burglary. Sticking with the burglary metaphor for a moment, the situation we’ve found ourselves in with WordPress plugins renaming the table prefix is like security vendors who sell you different ways to turn out the lights in your home to help keep you secure. It’s absurd.

When you change your table prefix in WordPress you usually use a WordPress security plugin to do the job. Unfortunately the security plugin needs to execute as the change is taking place. That means that during execution, half your tables have one prefix, and the other half have another prefix. If execution stops for any reason you are left with a broken website that you need to restore from backups.

Any plugin that makes this change also needs to modify your wp-config.php file successfully. This file may not be writable under certain conditions which can cause the change to fail.

While preparing for this post, I actually tried to change the WordPress table prefix using a security plugin on one of my test servers. For some reason it changed the wp-config.php file but failed to change the database table names. I think the issue may have been that the database user did not have the correct permissions.

The result was that when I refreshed my admin page, I was confronted with the “Welcome” page that you see when you first install a fresh WordPress. My site had disappeared.

Changing the WordPress table prefix is what we refer to in the industry as ‘security theater’. In other words, it is busy-work that makes you feel more secure but does nothing to make you more secure. It only adds risk and complexity.

We have another cool sounding phrase that describes this: ‘Security through obscurity’. What this means is that you’re trying to secure yourself by making things harder for an attacker to find. In the security industry this is widely accepted as a pointless exercise.

Things that do actually make you more secure against attacks are a WordPress Firewall, like the one included free with Wordfence. This actually blocks SQL injection attacks before an attacker can gain access to your database.

The Wordfence firewall includes rules to block SQL injection attacks. It even includes a sophisticated SQL parsing engine that understands SQL the same way a database does. When we see incoming SQL, we intelligently parse it to determine if the intent is malicious or not. If it’s a SQL injection attack, we block it. If we detect it’s a site user or administrator doing something safe like posting a blog post, we allow it through.

This site uses the Wordfence Firewall and while I was posting this blog post, which includes sample SQL, I wasn’t blocked. Wordfence is smart enough to know that I’m not doing anything bad. But if Wordfence sees a SQL injection attack, it will block it immediately.

I hope this has shed some light on a misunderstanding in the WordPress community that exists for legacy reasons. Please share this with the larger community to help us all focus on implementing real security measures that keep us all safe.